Subject: DLSw Multicast Spec

From: [email-masked]
Date: Tue, 8 Oct 96 10:29:59 EDT

Dave, I'm resending my note in case you didn't get it.

In summary, I guess my vote would be no.  I don't think we should
postpone.  Either solve now or abandon entirely.

Jon Houghton (IBM Corporation)

=========================================================================

Dave,

I agree with your summary below that the only non-minor stumbling
block is the single TCP session bring-up and addressing it in v1.1
could delay approval by November.

As I see things, we have three alternatives .....

1) Postpone v1.1 of RFC 1795 until a proposal (either part of the
scalability doc or a seperate doc) has been written and approved
for the handling of single TCP session bring-up.

2) Decide that single TCP session bring-up is not going to be
addressed.  This allows us to get v1.1 approved and closed soon.

3) Go ahead and get v1.1 approved and closed, but address the single
TCP session bring-up in v1.2 or later (your suggestion I think).
This alternative has major repurcusions.  If we address the issue
in v1.1, we can tie single TCP session bring-up and unicast/multicast.
That is, if we receive a unicast ICRex, we know we can bring up a
single TCP session to port 2067.
If we postpone addressing single TCP session bring-up until v1.2 or
later, we cannot tie it with unicast/multicast.  That is, if we receive
a unicast ICRex, we do not know whether the partner supports bringing
up a single TCP session on port 2067.  To know this would require
some prior exchange (like capex) or information in the ICRex (yucch)
or ....
In short, a proposal in v1.2 is going to be much different and more
complicated than one in v1.1.

It is our opinion that we should go with either option 1) or 2), but
not 3).  We do not have a strong preference between options 1) or 2).

Jon Houghton (IBM Corporation)

>> ------------------------------- Referenced Note ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>    Wed, 02 Oct 96 22:37:09 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>>           id AA18480; Wed, 2 Oct 1996 22:36:50 -0400
>> Date: Wed, 2 Oct 1996 22:36:50 -0400
>> Message-Id: <[email-masked]>
>> Errors-To: [email-masked]
>> Reply-To: [email-masked]
>> Originator: [email-masked]
>> Sender: [email-masked]
>> Precedence: bulk
>> From: David.Bryant/HQ/[email-masked]
>> To: [email-masked]
>> Subject: DLSw Multicast Spec
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>> X-Comment:  DLSw scalability issues
>>
>> Guys -
>>
>> Before I write anything down, let me see if I can gain concensus.
>>
>> Seems we're all in relative agreement on all the nit issues
>> and the main sticking point is what to do about single tunnel
>> bring-up.   Here's my analysis of the situation:
>>
>> - I think single tunnel bring up is an important extension
>> that should be part of the standard.
>>
>> - I think it's highly desirable to come out with it in the
>> initial spec.  But either way, we need to accomodate migration
>> and interoperability issues with existing dual tunnel activation
>> ala RFC 1795.
>>
>> - It appears as though the use of a different destination
>> port number (2067)provides an adequate means for providing the
>> migration path.
>>
>> - I think there are two paths single tunnel can go:
>>  Use TCP to resolve race conditions
>>  Add race condition state machines into DLSw
>>
>> - Either way, I think we'll either encounter issues or spend
>> time developing state machines and we won't stay on schedule for
>> a November CP date.
>>
>> So given this analysis of the situation, here's my suggestion:
>>
>> I suggest we complete the spec stating dual tunnel bring-up ala
>> RFC 1795.  We follow-up with an optional enhancement for single
>> tunnel bring-up in the next iteration. Likely, we'll base the
>> enhancement on the port 2067 thing, thus allowing smooth migration
>> and interoperability.  This way, will give ourselves some more
>> time to work out the appropriate single-tunnel solution.
>>
>> All those who object,let me know asap... so I can complete writing
>> and keep this thing moving. If you agree, please post agreement
>> asap as well.  This way I'll know people have read it and agree.
>>
>> Thanks, Dave
>>
>>
>>